Bug 1244428

Summary: "no linklocal address configured on ethmain.5" in F22
Product: [Fedora] Fedora Reporter: Pete Zaitcev <zaitcev>
Component: radvdAssignee: Pavel Šimerda (pavlix) <psimerda>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: jpopelka, psimerda, tomek, zaitcev
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-19 09:57:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pete Zaitcev 2015-07-18 17:17:21 UTC
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:

Comment 1 Pete Zaitcev 2015-07-27 20:37:34 UTC
I rebuilt radvd-2.11-3 from the source from Koji, but it fails the same.

Comment 2 Pavel Šimerda (pavlix) 2015-08-05 13:23:59 UTC
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?

Comment 3 Pete Zaitcev 2015-08-05 14:15:48 UTC
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.

Comment 4 Pavel Šimerda (pavlix) 2015-08-19 09:57:15 UTC
(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.