Description of problem: After upgrade to Fedora 22, the router stopped advertizing IPv6. With "IgnoreIfMissing off;" in radvd.conf, radvd refuses to start and reports the following: Jul 18 11:02:00 elanor radvd[1617]: no linklocal address configured on ethmain.5 In actual fact, the link-local address is configured as before: [root@elanor zaitcev]# ip addr show dev ethmain.5 4: ethmain.5@ethmain: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 00:23:54:9f:be:a5 brd ff:ff:ff:ff:ff:ff inet 192.168.128.1/24 brd 192.168.128.255 scope global ethmain.5 valid_lft forever preferred_lft forever inet6 fd2d:acfb:74cc:1::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80:0:0:1::1/64 scope link valid_lft forever preferred_lft forever [root@elanor zaitcev]# Version-Release number of selected component (if applicable): radvd-2.8-1.fc22.i686 NetworkManager-1.0.2-1.fc22.i686 How reproducible: Reboot Steps to Reproduce: 1. Configure radvd 2. Reboot Actual results: No IPv6 on the network Expected results: Working like in Fedora 21 Additional info:
I rebuilt radvd-2.11-3 from the source from Koji, but it fails the same.
Have you already tried to restart radvd just after verifying that you actually have an IPv6 link-local address? Is the problem specific to VLANs?
Yes, restarts were done over the configuration of ethmain.5 as listed in the original report. fe80:0:0:1::1/64 is on it.
(In reply to Pete Zaitcev from comment #3) > Yes, restarts were done over the configuration of ethmain.5 as listed > in the original report. fe80:0:0:1::1/64 is on it. Thanks! (In reply to Pete Zaitcev from comment #0) > inet6 fe80:0:0:1::1/64 scope link > valid_lft forever preferred_lft forever How was fe80:0:0:1::1/64 assigned? This is not a typical IPv6LL address and according to [1] not even a valid one. [1]: https://tools.ietf.org/html/rfc4291#section-2.5.6 It is more than likely that radvd is looking for a valid fe80::/64 and doesn't find one. Please talk to upstream if you think radvd should make an exception and allow more than what is specified by the standardh. Please reopen and reassign thins bug if the address is created by another Fedora component. Closing the bug for now as the component's behavior doesn't seem to contradict the respective internet standard.