I also tried to come up with a test for this. However I don't have a fedora VM right now to test it:

diff --git a/test/test-network/conf/25-tun.network b/test/test-network/conf/25-tun.network
new file mode 100644
index 0000000000..bbfba362b3
--- /dev/null
+++ b/test/test-network/conf/25-tun.network
@@ -0,0 +1,5 @@
+[Match]
+Name=tun99
+
+[Network]
+Address=fe80::1
diff --git a/test/test-network/systemd-networkd-tests.py b/test/test-network/systemd-networkd-tests.py
index 1062f93e55..82d50f3f2f 100755
--- a/test/test-network/systemd-networkd-tests.py
+++ b/test/test-network/systemd-networkd-tests.py
@@ -1160,15 +1160,20 @@ def test_veth(self):
 
     def test_tun(self):
         copy_unit_to_networkd_unit_path('25-tun.netdev')
+        copy_unit_to_networkd_unit_path('25-tun.network')
         start_networkd()
 
-        self.wait_online(['tun99:off'], setup_state='unmanaged')
+        self.wait_online(['tun99:routable'], setup_state='managed')
 
         output = check_output('ip -d link show tun99')
         print(output)
         # Old ip command does not support IFF_ flags
         self.assertRegex(output, 'tun (type tun pi on vnet_hdr on multi_queue|addrgenmode) ')
 
+        output = check_output('ip -6 addr show tun99')
+        print(output)
+        self.assertRegex(output, 'inet6 fe80::1')
+
     def test_tap(self):
         copy_unit_to_networkd_unit_path('25-tap.netdev')
         start_networkd()

I am not sure link_ipv6ll_enabled is right point to decide this. IPv6 link local addresses only need multi-cast for duplicate address detection not necessary a l2 network. Tinc vpn for example supports multicast in layer3 mode.

Right now I consider issue a blocker for the next release because it will break VPN setups.

I am not sure link_ipv6ll_enabled is right point to decide this. IPv6 link local addresses only need multi-cast for duplicate address detection not necessary a l2 network. Tinc vpn for example supports multicast in layer3 mode.

Or, then link_dhcp6_enabled() (which is an alias of link_dhcp_enabled()) and link_ipv6_accept_ra_enabled() should be updated?

I think, we should also update link_ipv4ll_enabled(), as IPv4LL also requires MAC address.

I cannot use link_dhcp6_enabled either because there is link_ipv6_accept_ra_enabled which is true for my interface. So it would still break the configuration. I don't know why it also checks for link_ipv6_accept_ra_enabled?

I cannot use link_dhcp6_enabled either because there is link_ipv6_accept_ra_enabled which is true for my interface. So it would still break the configuration. I don't know why it also checks for link_ipv6_accept_ra_enabled?

As, RA may request to start dhcp6 client. So, please not only link_dhcp6_enabled() but also link_ipv6_accept_ra_enabled() should be updated.

BTW, I noticed that link_dhcp6_enabled() does not call link_ipv6ll_enabled(), But IPv6LL is required in link_acquire_ipv6_conf()... We may need whole logic/conditions of configuring/starting dhcp6 client and ndisc.

And, half of the list of interface kind in link_ipv6ll_enabled() are interfaces which do not have MAC address. Maybe, we should add link_has_mac_address() or something and use it at appropriate places.

Would this not break multi-cast network interfaces that support router advertisement but don't have MAC addresses? cc @andir

UPDATE ok. let's go this route, but longterm it would be good not to depend on having ethernet for dhcpv6/router advertisment.

Actually ndisc_configure can handle cases with no ipv6 addresses.

@yuwata it now defaults to DUID_TYPE_EN for devices without mac addresses. If you like this solution I will also update the documentation accordingly.

Thanks. LGTM.